Carlos Garnacho [Wed, 3 Feb 2021 11:07:34 +0000 (12:07 +0100)]
st/scroll-view: Make fade effect take ClutterMargin
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Carlos Garnacho [Wed, 3 Feb 2021 11:03:11 +0000 (12:03 +0100)]
st/viewport: Add clip-to-view property
This property controls whether the viewport clips the content to its own
allocation or not. This will be necessary in special modes that we want to
render past the viewport inside a scrollview.
Florian Müllner [Sat, 20 Feb 2021 10:18:29 +0000 (11:18 +0100)]
workspacesView: Add minimap on secondary monitors
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.
That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.
Florian Müllner [Sat, 20 Feb 2021 12:34:39 +0000 (13:34 +0100)]
workspacesView: Decrease workspaces size on external monitors
Now that the backgrounds was moved into workspaces, the fullscreen
views on secondary monitors are visually inconsistent with the
primary view, as there's no dash or search entry that reduces the
available height and allows adjacent workspaces to peek in.
Address this by adding padding above and below the view, so that
it is limited to 70% of the available height.
Florian Müllner [Fri, 19 Feb 2021 21:03:07 +0000 (22:03 +0100)]
workspacesView: Split out SecondaryMonitorDisplay
Right now the handling of external monitors is relatively simple, and
consists of putting either an extra workspace or a full view on the
monitor, depending on the workspaces-only-on-primary setting.
We are about to tweak the behavior on secondary monitors, prepare for
that by splitting out an intermediate actor that manages the views on
non-primaries.
Florian Müllner [Sat, 20 Feb 2021 12:33:29 +0000 (13:33 +0100)]
workspacesView: Center extra workspace
At the moment views on non-primary monitors take up the entire work area,
so simply allocating the available size works. However we'll soon shrink
the views a bit to match the visuals on the primary monitor. As workspaces
keep the ratio, reducing their height will also reduce the width; override
the default allocate() to keep the extra workspace horizontally centered.
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.
Florian Müllner [Tue, 2 Mar 2021 10:45:31 +0000 (11:45 +0100)]
workspaceThumbnail: Initialize porthole to work area
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.
That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.
Florian Müllner [Sat, 20 Feb 2021 11:44:01 +0000 (12:44 +0100)]
workspaceThumbnails: Disconnect signals on destroy
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.
Florian Müllner [Wed, 15 Nov 2017 17:15:49 +0000 (17:15 +0000)]
overviewControls: Shift up on double-super
Right now a second super press during the overview transition hides
the overview again. Change that behavior to shift up to the app grid
instead, which is more useful.
Carlos Garnacho [Mon, 1 Mar 2021 17:13:02 +0000 (18:13 +0100)]
appDisplay: Move onto the correct page while DnD on both LTR/RTL
Look up the next page correctly for the overshoot coordinates, given
the text direction. We don't need to look whether there is a next
page either, as goToPage() checks that it's the case.
Sebastian Keller [Wed, 24 Feb 2021 22:22:52 +0000 (23:22 +0100)]
windowPreview: Unset selected if window was clicked to switch workspaces
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.
Florian Müllner [Fri, 26 Feb 2021 21:55:57 +0000 (22:55 +0100)]
overview: Unset visibleTarget on gesture end
The property describes the target visibility (that is, the visibility
that will be set after the ongoing transition), and is therefore updated
at the start of the transition rather than from hideDone().
The overview gesture currently misses resetting it at the end, so it
is only updated to the correct state the next time the overview is
entered.
Florian Müllner [Thu, 25 Feb 2021 23:47:48 +0000 (00:47 +0100)]
extensionUtils: Simplify version check
When adapting the check to the new versioning check, we just blindly
copied the old behavior for stable/unstable versions:
- stable releases must have matching major numbers
- unstable releases must match major and minor ("alpha", "beta", "rc")
That worked for the old even/odd scheme, but now has the absurd effect
that we consider an extension that lists "40.alpha" in its shell-version
incompatible with "40.beta", but compatible with "40.2".
At least this provides us with a good opportunity to reconsider the
behavior. While it is true that breakage is much more likely between
unstable releases, in practice extensions are either following shell
development closely or update once around the time of a stable release.
For the former, the stricter check isn't usually too useful (as the
extension releases around the same time as gnome-shell anyway).
For the latter, it's annoying that ".rc" is treated differently from
".0" and requires an update to become compatible.
The latter is also by far the more common case, so update the check
to only match on the major version regardless of whether a release
is stable or unstable.
Florian Müllner [Fri, 26 Feb 2021 13:46:22 +0000 (14:46 +0100)]
ci: Add commit rule to not end subject with punctuation
I recently forgot to fill in the subject after the prefix. Add a
commit rule for catching this and other cases where subject lines
end in punctuation (except ...)
Florian Müllner [Fri, 26 Feb 2021 12:36:26 +0000 (13:36 +0100)]
workspaceThumbnail: Consider porthole offsets
Since commit 9980c806191f, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).
To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.
The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.
Sebastian Keller [Sun, 21 Feb 2021 17:38:05 +0000 (18:38 +0100)]
windowPreview: Ensure scaling is limited to defined size increase
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.
To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.
Florian Müllner [Wed, 24 Feb 2021 01:28:09 +0000 (02:28 +0100)]
lightbox: Fix shader effect
Since commit 0f1b566918e, we use gjs' automatic getters/setters for
the shader properties. Those handle the properties on the JS and
GObject side, but they don't update the corresponding uniform,
whoops.
Revert the lightbox bits of commit 0f1b566918 to get the effect back.
Jonas Ådahl [Tue, 23 Feb 2021 17:24:35 +0000 (18:24 +0100)]
main: Move NO_AT_BRIDGE hack to mutter
There is no guarantee that it'll have effect, since the time anything
that'll look at that environment variable is not known by gnome-shell.
Let mutter carry this burden instead.
Allan Day [Fri, 19 Feb 2021 15:58:18 +0000 (15:58 +0000)]
schemas: Define default app grid arrangement
Specify the default app grid arrangement. This makes the app grid
more useful since the interesting apps are prioritised. It also
communicates that the app grid can be customised.
Jonas Dreßler [Tue, 16 Feb 2021 22:11:30 +0000 (23:11 +0100)]
workspace: Don't limit workspaceBox size when doing app grid animation
In the allocate() vfunc of WorkspaceLayout we use a small trick to make
the nonlinear animation paths when opening the overview less jarring:
Because a window might get smaller than its target size during the
animation, we make sure the size never drops below the final size
calculated by the layout strategy.
In the app grid the Workspace is very small though, and the size of a
window slot calculated by the layout strategy might actually be larger
than the workspaceBox. This means we might use the window slot size
instead of the workspaceBox size and end up with a window that's at the
correct position, but its size is too large.
Fix this by only applying this trick when we're animating towards or
from the state where we actually expect the workspaceBox to be larger
than the window slot, that is during the the transition from the session
to the window picker (or the other way round).
Jonas Dreßler [Mon, 8 Feb 2021 17:58:27 +0000 (18:58 +0100)]
workspace: Properly handle zero spacing in the WorkspaceLayout
It should be allowed to set this._spacing to 0 and thus pass 0 as
rowSpacing or colSpacing to this._adjustSpacingAndPadding(). The current
if-condition there won't add the oversize to the spacing in case 0 is
passed though.
So change that if-condition and explicitely check for null instead.
Window previews can spill out of the container when their position in the
session overflows the monitor boundaries. In the past, Workspace didn't have
a visible background, and was (almost) always fullscreen, which would mask
this particular problem. However, nowadays, it is very much noticeable when
this situation happens.
Clip the window previews container to its allocation when the overview state
is bigger than WINDOW_PICKER. That is, between HIDDEN and WINDOW_PICKER states,
inclusive, no clipping is applied.
workspace: Add WorkspaceBackground to Workspace itself
Instead of adding it to the window previews container, add it to Workspace
itself. This requires expanding WorkspaceBackground, so add the relevant
x and y expand flags.
Since the background is beneath the window previews, create and add it before
the window preview container.
workspace: Move window previews to a child container
Currently, Workspace is a single actor that contains both the background,
and all window previews, and is managed by WorkspaceLayout. In the future,
this concentrating aspect of it will bite us; we want the window previews
to be clipped to the allocation, but not the background, since it will
have shadows.
Make Workspace subclass St.Widget with a ClutterBinLayout as layout manager,
and move window previews to a child actor. To reduce the impact of this
extra actor, it's a ClutterActor instead of a StWidget, and the spacing is
still set on Workspace itself.
The WorkspaceBackground class has specific code to clip the background
to the workarea. However, it doesn't monitor for workarea changes, which
means it cannot react after being created.
Connect to 'workareas-changed', and update the workarea, the radius bounds,
and relayout when workareas change.
workspacesView: Only clip non-primary workspace views
The primary workspace is displayed in the overview, and clipping it
ends up clipping the shadows too. Since Overview's ControlsManager
itself clips to allocation, no windows in the primary monitor spill
to other monitors. However, not clipping non-primary monitors might
end up in situations where their windows spill into the primary one.
Make sure to only clip workspace views of non-primary monitors.
Evan Welsh [Sat, 20 Feb 2021 20:25:00 +0000 (12:25 -0800)]
schema: Enable extension version validation by default
Previously this was disabled to avoid requiring extensions to manually
update on each release. For 40 this behavior will likely be too unstable
for most users.
Florian Müllner [Fri, 19 Feb 2021 16:11:14 +0000 (17:11 +0100)]
welcomeDialog: Hide overview when taking tour
The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.
Jonas Dreßler [Mon, 8 Feb 2021 18:06:37 +0000 (19:06 +0100)]
windowPreview: Add scaled extra size to chromeWidths() and chromeHeights
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().
Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().
Jonas Dreßler [Mon, 8 Feb 2021 18:02:23 +0000 (19:02 +0100)]
windowPreview: Scale up by the same extra size for every window
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.
So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.
Jonas Dreßler [Tue, 9 Feb 2021 11:18:29 +0000 (12:18 +0100)]
windowPreview: Use a proper spacing between icon and title
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).
So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.
Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.
Florian Müllner [Tue, 16 Feb 2021 18:37:38 +0000 (19:37 +0100)]
windowManager: Keep a minimum number of workspaces
The scaled down workspace in the window picker looks lonely when there's
no adjacent workspace peeking in. Avoid that by always keeping a minimum
of two workspaces.
Florian Müllner [Tue, 16 Feb 2021 19:15:21 +0000 (20:15 +0100)]
workspaceThumbnails: Only show for more than two workspaces
As adjacent workspaces now peek into the window picker, the first
two workspaces are already accessible without the minimap. Hide
it in that case to give more space to the window picker, and to
not clutter the overview for users who aren't using workspaces.
Florian Müllner [Wed, 17 Feb 2021 19:13:22 +0000 (20:13 +0100)]
workspaceThumbnail: Do not update scale while collapsing
The scale property tracks the relative size at which we display thumbnails
given the space we have available.
That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.
Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.
Florian Müllner [Tue, 16 Feb 2021 21:03:29 +0000 (22:03 +0100)]
workspaceThumbnails: Animate showing/hiding
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.
However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.
Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.
Florian Müllner [Tue, 16 Feb 2021 19:40:43 +0000 (20:40 +0100)]
workspaceThumnails: Add :should-show property
We currently have two components that show or hide the minimap:
- the thumbnails hide themselves in case of a single static workspace
- overview controls show the minimap when no search is active
That obviously doesn't work correctly.
To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.
Florian Müllner [Wed, 17 Feb 2021 19:31:33 +0000 (20:31 +0100)]
workspaceThumbnail: Base n-workspaces on number of thumbs
It's what we base our size request on, and what we actually allocate.
The difference usually doesn't matter right now, but will soon when
we animate the minimap itself.
Florian Müllner [Tue, 16 Feb 2021 22:06:37 +0000 (23:06 +0100)]
workspaceThumbnails: Actually use vscale parameter
We pass two scales to setScale(), but only use the first one for
both horizontal and vertical scaling. We'll soon have a use case
for using a different scale for each dimension, so start using
both parameters.
Jonas Dreßler [Thu, 18 Feb 2021 21:10:02 +0000 (22:10 +0100)]
theme/window-picker: Fixup box-shadow of overview workspace backgrounds
A small mistake snuck in right before landing the previous commit and
the box-shadow was moved 4px vertically above the wallpaper instead of
below it. Fix that and put it 4px below the wallpaper.
Jonas Dreßler [Mon, 8 Feb 2021 15:43:32 +0000 (16:43 +0100)]
theme/window-picker: Add box-shadow to the workspace background
According to the GNOME 40 mockups, add a box-shadow to the workspace
background. For this to work, we also need a background-color (St
limitations), and to make sure that background-color doesn't bleed over
the rounded corners of the wallpaper, we also need to tell St to use a
border-radius and clip the background-color painting using a rounded
path.
Jonas Dreßler [Mon, 8 Feb 2021 15:33:06 +0000 (16:33 +0100)]
workspace: Round the corners of the wallpaper
As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.
To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.
Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.
Florian Müllner [Sat, 13 Jun 2020 11:26:09 +0000 (13:26 +0200)]
overviewControls: Add shortcut for shifting through overview
This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.
workspacesView: Disable mouse drag to switch workspaces
During the user research, it was found that users would instinctively
drag the workspace horizontally but would often, in the process,
accidentally drag a window.
Disable dragging workspaces using the cursor for now.
Florian Müllner [Wed, 17 Feb 2021 00:46:04 +0000 (01:46 +0100)]
dash: Put the dot back into its box
When commit 3a9acb96 moved around padding to extend the clickable
area to the screen edge, it reduced the inner padding too much and
the running indicator ended up outside the highlighted area.
Carlos Garnacho [Thu, 11 Feb 2021 12:08:47 +0000 (13:08 +0100)]
layout: Move keyboard slide animation to keyboard
The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.
This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.
The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.
Carlos Garnacho [Tue, 16 Feb 2021 23:57:13 +0000 (00:57 +0100)]
overview: Synchronize panel opacity with overview leave animation
Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.
Carlos Garnacho [Mon, 4 Jan 2021 15:23:45 +0000 (16:23 +0100)]
overview: Make 3fg vertical swipes bring overview and app grid
The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.
Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.
Carlos Garnacho [Thu, 11 Feb 2021 23:20:31 +0000 (00:20 +0100)]
overviewControls: Add "gesture-in-progress" property on the state adjustment
This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.
Carlos Garnacho [Thu, 11 Feb 2021 23:24:13 +0000 (00:24 +0100)]
workspacesView: Initialize/update swipe orientation before gesture
Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.
But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).
Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.
projects / gnome-shell.git / log